【レポート】サービス責任者が語る Amazon Aurora MySQL/PostgreSQL の詳細と内部構造 #AWSSummit
こんにちは、崔です。
AWS Summit Tokyo 2019 2日目のD2-05のセッションである「サービス責任者が語る Amazon Aurora MySQL/PostgreSQL の詳細と内部構造」のレポートをお届けします。
このセッションでは、クラウドの技術革新を活用するためにゼロから設計された、クラウドネイティブデータベースサービスであるAmazon Auroraについて詳しく説明します。 Auroraはその記憶域として分散型マルチテナントログ構造化ストレージサービスを使用するなど、モノリシックデータベーススタックをサービス指向アーキテクチャに移行しています。 Auroraは、低レイテンシーレプリカなど、数々の革新的な機能を備えています。このセッションでは、主なイノベーション、パフォーマンス結果とその達成方法の確認、そして実際のアプリケーションについてお話しします。
スピーカー
Amazon Web Services, Inc.
Aurora, MySQL, and MariaDB
Senior Product Manager
Amazon Aurora
- マネージドサービス
- 商用DBの性能と可用性
- オープンソースDBのシンプルさとコスト効果
- MySQL/PostgreSQLと互換性がある
- 利用した分だけのお支払い
Auroraの性能と拡張性
Auroraのscale-out, ditributed architecture
- log-structured 分散ストレージシステム
- それぞれのAZに２つずつ、計6つのデータのコピーを保存
- データは10GBずつ保存され、64TBまで自動的にスケールアップ
- 事前に増やしておく必要はない
Six-way replicated storage
- データは6ノードに非同期・並列で書き込む
- 書き込みクォーラムは4ノード, 読み込みクォーラムは3ノード正常であればOK。
Write quorum in action
- 4つのディスクに書き込まれた時点でコミットされる
I/O flow in Aurora storage node
- 1.ログレコードを受信してインメモリキューに追加
- 2.ホットログをACKでレコードを保持
- 3.レコードを整理し、ログのギャップを特定
- 4.ギャップを埋めるためにゴシッププロトコルを利用
- 5.ログレコードを新しいページバージョンに結合
- 6.定期的にログと新しいページのバージョンをS3に保存
- 7.定期的に古いバージョンをガベージコレクション
- 8.ブロックのCRCコードを定期的に検証
全てのステップは非同期
Write and read throughput
- Aurora MySQL is 5x faster than MySQL
Bulk data load performance
- Aurora MySQL loads data 2.5x faster than MySQL
- Aurora PostgreSQL loads data 2x faster than PostgreSQL
Continuous HW upgrades to boost performance
- Aurora MySQL - 2015 to 2018
- Max write throughput - up 100%
Aurora Read Replicas
- 複数のAZに最大15の昇格可能なリードレプリカ
- REDOログベースの（物理）レプリケーションにより、レプリカの遅延が低い（通常10ms未満）
- フェイルオーバーの順序を設定可能なカスタムリーダーエンドポイント
MySQL vs Aurora I/O profile
- MySQL I/O profile for 30 min Sysbench run（MySQL with Replica）
- 0.78MM transactions
- 7.4 I/Os per transaction
- Aurora I/O profile for 30 min Sysbench run
- 27MM transactions 35倍以上
- 0.95 I/Os per transaction 7.7倍弱
- MySQLのレプリカ構成に比べ、Auroraのリードレプリカ構成の方が、I/O量が少なく済み、トランザクション量が35倍以上可能となる
Aurora read replicas are dedicated to reads
- MySQL READ Replica
- 論理的な完全な変更
- マスターと同じ書き込みワークロード
- 独立したストレージ
- Aurora Read Replica
- 物理的な差分の変更
- 書き込みが発生しないレプリカ
- シェアードストレージ
Aurora read scaling options
- クラスタごとに昇格可能な15台のリードレプリカ
- 自動的に追加・削除を行うAuto-Scalingレプリカ
- リージョンを跨いだリードレプリカ
- MySQLからbinlogを利用したレプリケーション
Aurora Grobal Database
- Faster disaster recovery and enhanced data locality
- リージョンを跨いだリードレプリカ
- High throughput : Up to 200K writes/sec
- ディスクレイヤーでのリージョン間コピー
- Low replica lag : < 1 sec cross-country lag
- レプリケーションの遅延が非常に小さい
- Fast recovery : < 1 min region unavailability
Aurora Parallel Query
- Auroraストレージには数千のCPUが存在する
- クエリ処理をプッシュダウンして並列化
- 処理をデータ近くに移動することでネットワークトラフィックと待ち時間を削減
- 実現のためには多くのチャレンジ
- データは範囲分割されていない。フルスキャンが必要
- データは実行中の可能性がある リードビューでは最新のデータを表示できない場合がある
- すべての機能をプッシュダウンできるわけではない
Parallel Query performance results
- NETFLIX事例
- Parallel Queryを使うことで、インスタンスタイプをr3.8xlargeからr3.2xlargeに減らすことができた
- パラメータをONにすれば良いだけ
Aurora lock management
- MySQL lock manager
- MySQLと同じロックセマンティクス
- ロックチェーンへの同時アクセス
- Aurora lock manager
- 個々のロックチェーン内の複数のスキャナ
- ロックフリーデッドロック検出
- 多くの同時セッションをサポートする、高い更新スループット
Aurora availability & management
Instant crash recovery
- Traditional database
- 最後のチェックポイント以降からログを適用する必要
- チェックポイント間は通常5分
- MySQLではシングルスレッド。大量のディスクアクセスが必要
- Amazon Aurora
- ストレージがディスク読み取りの一部としてREDOレコードをオンデマンドで再適用
- 並列、分散、非同期
- 起動時に再適用なし
Cluster Cache Management - Aurora PostgreSQL（最新リリース機能！）
- Avoiding a cold cache after failover
- データベースをフェイルオーバーしてキャッシュをウォームアップするにはしばらく時間がかかる
- DBの起動に32秒、パフォーマンスの回復には340秒かかっていた
- それが、パフォーマンスの回復が、ほぼ起動と同タイミングにまで可能となった！！！
- PostgreSQL 準拠の Amazon Aurora がクラスタキャッシュ管理をサポート
Aurora Backtrack
- Backtrackにより、バックアップからの復元を必要とせずにデータベースを特定の時点に戻すことが可能
- 意図しないDMLまたはDDL操作から回復
Fast Database Cloning
- 重複したストレージコストなしでデータを重複してもてる
- クローンストレージはポインターのみを持つ
